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(54) Remote financial transaction system 

(57) A systenn for performing remote financial trans- 
actions using a payment module having access to a 
memory and having communication with an off-site 
processing system, such as through an interactive net- 
work. The payment module accesses payment account 
information and corresponding PIN information stored in 
the memory. A user may select a financial transaction 
and a payment account to access for performing the fi- 
nancial transaction. The PIN and required payment ac- 
count information are retrieved from the memory, en- 
crypted and transmitted through the interactive network 
ultimately to the financial institution maintaining the ac- 
count. The financial institution may make an approve/de- 
cline decision and may send an approve/decline mes- 
sage to the user through the interactive network. 
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Description 

Background Of The Invention 

The present invention relates to a method and ap- 
paratus for securing and conducting financial transac- 
tions from remote locations, in which there is communi- 
cation between the remote location and off-site transac- 
tion recording or processing locations. 

Various techniques have been developed for main- 
taining security and secrecy of remotely conducted fi- 
nancial transactions. Such techniques commonly rely on 
the use of secret passwords, which typically are called 
personal identification numbers, or PINs. In a transac- 
tion, the PIN generally is used in conjunction with a sec- 
ond form of identification which is physically scanned by 
a reading device. 

One known technique for remote transactions are 
bank automatic teller machines ("ATMs") and electronic 
fund transfer at point-of-sale terminals ("EFT-POS" ter- 
minals). Typical ATMs and EFT-POS terminals require 
the user to insert a card containing an encoded magnetic 
strip. Information is read from the magnetic strip. For ex- 
ample. Track 1 information may be read., including the 
user's name, account number, card validation value 
("C VV") and expiration date. In addition, the user typical- 
ly is required to input a PIN in order to commence any 
transactions. The PIN typically is assigned by a register- 
ing institution, such as a bank or credit card company. In 
one approach, the registering institution assigns the PIN 
to the user. In other approaches, the user is able to 
self-select a PIN. In a self -selection system, the user can 
personally visit the registering institution and make the 
selection there. The automatic teller machine typically is 
at location removed from the user's home. 

ATM and EFT-POS networks are also known. One 
such network is described in the ANSI X9.24 standard. 
In such a network. ATM (or EFT-POS) machines from 
different financial institutions ar-e connected through a 
central processing institution. Using such networks, for 
example, a user with an account at a particular bank may 
conduct financial transactions, such as bank account 
withdrawals, from a different bank. Such networks are 
widely known and have such trade names as "NYCE", 
"PLUS" and "CIRRUS". In a typical network, the ATMs 
of one bank are connected to a data processing unit of 
that bank. Other banks connected to the network have 
similar ATM arrangements. The data processing units of 
each bank on the network are in turn connected to a cen- 
tral processing institution. The central processing insti- 
tution thereby acts as a router or a financial network 
switch sending transaction requests to the appropriate 
bank on the network. 

ATM systems have been subject to various forms of 
hostile attack. For example, the PINs are accessible be- 
cause users must input them into the system by the user 
in an unencrypted form. Although the ATM terminals typ- 
ically encrypt the PINs before transmitting them from the 



terminals over the ATM network, they typically use one 
encryption key for multiple PINs. Thus, they also have 
been subject to dictionary attack in which a known PIN 
is used as an attack base. When the known encrypted 

5 PI N is intercepted by a monitor (such as by detecting the 
associated unencrypted account information), and when 
an identical encrypted PIN is intercepted (corresponding 
to a different account), then the PIN for that account is 
known because the same encryption key is used. 

TO Vanous techniques are known for selecting and en- 
crypting the PIN from a remote site, rather than in person 
at the registering institution. A paper encryption system 
is described in United States Patents Nos. 4,870,683 
and 4,885,779. Using the paper encryption system the 

^5 user may select and encrypt the PIN at home and then 
mail it to the registering institution. The user also may 
transmit the encrypted PIN to the registering institution 
over the telephone lines. In another known technique for 
selecting and encrypting a PIN at a remote site, the user 

20 communicates with the encryption system electronically 
(such as via modem communication) and sends an iden- 
tifier and receives back an encrypted identifier Such a 
system is described in commonly-assigned co-pending 
United States Patent Application Senal No. 08/029.833. 

25 Various unsecured at-home purchasing systems are 
known. One such system is television home shopping. 
Typical television home shopping systems include he 
QVC network and the Home Shopping Channel. In such 
television home shopping systems, broadcast program- 
me? ming is received by a television receiver The program- 
ming typically includes a descnption of the product being 
sold, a video display a price and ordering instructions. 
Typically, the user is provided a toll-free telephone 
number, such as an "800" number to call for placing an 

35 order The user may order using a credit card in which 
various information must be given to the order taker 
Such a system is unsecured because the telephone lines 
are subject to hostile attack, such as by monitors or 
eavesdroppers. Likewise, the credit card information is 

^0 not encrypted, so the attackers may obtain information, 
either through the telephone lines or at the order receiv- 
ing facility 

Other kinds of television services offer unsecured in- 
teractive ordering through a television receiver One 

-^5 such service commonly is offered in hotels for remote 
check-out processing from the hotel room. In such a 
service, the hotel guest is offered various check-out op- 
tions on the in-room television receiver For example, the 
guest may be offered various options, including review- 

so ing charges to the room, such as meal, daily board and 
telephone fees, and automatic check-out without per- 
sonally visiting the registration services desk in the ho- 
tel's lobby. The options are offered in a menu system ap- 
pearing on the television screen typically through a ca- 

S5 ble. The guest scrolls through the menus and selections 
using a remote control device, such as a typical televi- 
sion infra-red hand-held controller Likewise, the differ- 
ent menu options are selected using the hand-held con- 
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troller. Such a system does not enable payment directly 
through the television. Typically the hotel receives 
prs-payment. such as by preseMtation ol a credit card 
(and optionally additional identification) upon check-in 
registration at the front desk. In addition, the system is 
subject to hostile attack through intercepting the televi- 
sion signal, such as through the cable system, and 
through access to the hotel records pertaining to guest 
credit card information. 

Another interactive television ordering system is 
used for ordering or blocking pay-per-view movies. One 
such pay-per-view service, such as offered in hotel 
rooms, gives the user a selection of various movies to 
request (while the fee is added to the hotel bill), as well 
as the option to block out certain movies or all 
pay-per-view selections. As with the check-out system, 
the user may use a typical hand-held television or VCR 
remote control to scroll through the menus and make se- 
lections. Again payment may not be made directly by the 
user. Instead, the fees are added to the hotel or cable 
bill. Like the check*out system, this movie ordering sys- 
tem is subject to hostile attack. 

Computer bulletin board services provide another 
form of at-home purchasing. One such service is Com- 
puserve. 5000 Arlington Centre Blvd.. P.O. Box 20212, 
Columbus. Ohio 43220. In such systems, the user typi- 
cally communicates to a remote computer system from 
a personal computer A modem typically is used to initi- 
ate a telephone contact between the remote computer 
and the bulletin board system. The user may have the 
option of browsing various services and products offered 
for sale. Payment typically is made by credit card or by 
check through the mail. Such a system is subject to hos- 
tile attack, such as through telephone eavesdroppers 
and monitors, monitors with direct access to the bulletin 
board computer, hacker attack from off-site locations, or 
through access to the mail. 

Summary Of The Invention 

The present invention alleviates to a great extent the 
risks and disadvantages of the known techniques and 
apparatus by providing a secure remote financial trans- 
action system using password security as well as a se- 
cure method for selecting and implementing personal 
passwords. The present invention provides an appara- 
tus and method for performing remotely conducted finan- 
cial transactions over an interactive network using a pay- 
ment module such as an initialized remote control de- 
vice. 

More specifically, the payment module communi- 
cates with a receiving device which is connected to an 
interactive network, such as a television connected to a 
cable system, in order to conduct a financial transaction 
such as a purchase of goods or services. In other em- 
bodiments, the payment module is separate from the 
control device. 

In the preferred embodiment, a programming origi- 



nator provides goods and services for sale through 
broadcast or cable television. Alternatively, the goods or 
services may be provided through other known forms of 
interactive transmission, such as satellite transmission 

5 or computer communication through telephone lines. 
The user may view the programming and optionally scroll 
through different goods or services selections using a 
control device. If the user wishes to make a purchase or 
conduct a financial transaction, various options are pro- 

10 vided through on-screen graphical displays, such as 
menus. If a particular transaction, such as a purchase, 
is desired, the user selects that option from the graphical 
display. The user is prompted to enter a password (re- 
ferred to herein as a "PIN") into the control device. En- 

15 tering the PIN activates the payment module. The user 
may then select a payment method, such as any one of 
the user's various pre-initialized credit or debit cards. 

An encrypted PIN is stored in the payment module, 
corresponding to the unencrypted PIN. The payment 

20 module preferably encrypts the already encrypted PIN 
using the derived unique keys per transaction technique 
(the "DUKPT" technique) such as set forth for example 
in the ANSI X9.24 standard before sending it over the 
network. 

25 The payment module then sends the encrypted PIN 
(or doubly encrypted PIN) along with pertinent data (such 
as the credit or debit card's Track 1 or Track 2 data) 
through the interactive network (the "network"). The net- 
work's host system then sends this information to the ap- 

30 propriate financial institution, such as the acquiring bank, 
and the transaction is then passed through the financial 
network to the card issuer where the encrypted informa- 
tion is decrypted and the transaction is approved or de- 
clined. The approval/decline is sent back to the user and 

35 a corresponding approval/decline message appears on 
the user's display screen. 

The payment module is initialized in the preferred 
embodiment with its DUKPT keys. Identifying informa- 
tion corresponding to the desired credit and debit card 

-^0 also are entered into the payment module. Preferably 
this information is input in the form of a sequence of num- 
bers entered by the user into the payment module. Typ- 
ically this must only be done once for each desired card 
and is aided by graphical prompts and instructions ap- 

•^5 pearing on the user's monitor The user also preferably 
enters an encrypted version of the PIN corresponding to 
each card. A paper encryptor system as described above 
may be used to encrypt the PIN. The encryption key is 
not maintained in the payment module. 

50 it also is preferred that the user be required to select 
a persona! access password that will be used to control 
access to the payment module Multiple users may use 
the same payment module, each ,v;[h a personal access 
password controlling access to that user's own cards. 

55 Using the present invention, secure transactions are 

conducted without using a magnetic strip reader such 
as is required in existing systems such as ATM networks. 
Accordingly, the payment module may be less bulky than 
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a magnetic strip reader because the apparatus required 
for reading the magnetic strip are not required. 

Since the unencrypted PIN is never in the clear ei- 
ther in the payment module or in the interactive network, 
the system provides even greater security than is nor- 
mally provided in ATM networks or retail point of sale ter- 
minal. The PINs are stored in an encrypted form in the 
payment module and are not transmitted over the net- 
work in unencrypted form. The decryption keys (the 
"keys") are not maintained in the payment module. Rath- 
er, the keys are maintained only at the card issuer and 
are not in possession of any other entity within the net- 
work. 

In addition, unique keys are used (such as using the 
DUKPT technique and paper encryptor), frustrating hos- 
tile attack, including dictionary attack. 

tn addition, the payment module of the present sys- 
tem is fully compatible with existing ATM and point of sale 
networks. Further secunty is provided as described 
above through the use of encryption and password pro- 
tection. 

Furthermore, the transaction system of the present 
invention provides individual banks (and other payment 
account maintaining institutions) discretion regarding 
whether the remote financial transaction system may 
make use of accounts maintained by the individual bank 
as well as any terms of use. 

In addition, the apparatus of the present invention is 
more compact and less expensive than current means 
of conducting remote transactions. For example, the 
space and expense of magnetic stripe readers and dis- 
play screens (other than the user's existing display) are 
avoided. 

Brief Description Of The Drawings 

The above and other objects and advantages of the 
invention wilt be apparent upon consideration of the fol- 
lowing detailed description, taken in conjunction with the 
accompanying drawings in which like reference charac- 
ters refer to like parts throughout and in which: 

FIG. 1 is a diagram of a local system of the remote 
financial transaction system of the present inven- 
tion: 

FIG. 2 is a block diagram of a remote financial trans- 
action system of the present invention: 

FIG. 3 is a block diagram of a local system of the 
remote financial transaction system of the present 
invention: 

FIG. 4 is a block diagram of a local system of the 
remote financial transaction system of the present 
invention: 

FIG. 5 is a system block diagram of a payment mod- 



ule of the present invention; 

FIG. 6 is a flow chart showing a process for initializ- 
ing the payment module of the present invention; 

5 

FIG. 7 is a flow chart showing a process for conduct- 
ing a purchase transaction of the present invention; 
and 

10 FIG. 8 is a flow chart showing procedures conducted 
in a remote system for processing the purchase 
transaction of FtG. 7. 

Detailed Description Of The Invention 

15 

FIG. 1 illustrates a secure at-home payment system 
embodiment of the present invention. The user 1 0 oper- 
ates a payment module 20. In the illustrated embodi- 
ment, the payment module 20 incorporates a remote 
20 control device which communicates with a receiver. The 
communication with the receiver may be accomplished 
by any means of communication linking 30, such as over 
wires, or, preferably by non-wired transmission. Any form 
of non-wired linking may be used. Infra-red transmission 
25 typical in television remote control devices is preferred, 
but other forms on non-wired transmission also may be 
used. For example, microwave, sonic or radio wave 
transmissions may be used. 

The payment module and control device preferably 
30 are integrated into the same device as illustrated in FIG. 
1 . However, in other embodiments, the payment module 
may be incorporated in other apparatus components or 
may be a stand-alone device. Where the payment mod- 
ule is incorporated in other apparatus components, a re- 
35 rnote controller may be used to communicate with the 
payment module. Alternatively, a keyboard, joystick, 
mouse, or other form of controller may be used. 

Other at-home components of the payment system 
include a visual display screen 40, such as a television 
-to screen, and a connector 50 for accessing an interactive 
communications network 80 (illustrated in FiG. 2). 

Various forms of visual display screens 40 may be 
used. Preferably, a television is used, but a computer 
monitor liquid crystal display or other form of display may 
•^5 also be used. Likewise, a non-visual display may be 
used, such as an audio interface or telephone. 

In the preferred embodiment, the connector 50 is a 
cable connection of the type used to connect to television 
cable systems. Where the interactive communications 
50 network 80 is a cable system, a network interface 60. 
such as a cable box typically will also be used to com- 
municate over the network 80. The connector cable 50 
is connected to the cable box 60 as illustrated in FIG. 1 . 
The interactive network 80 may be any type of net- 
55 work in which data may be transmitted from the user's 
local system 100 to a remote system 200 and data may 
be received by the user through the network 80 from the 
remote system 200. In addition to television cable sys- 
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tems. various forms of interactive networks are known, 
including ATM networks, wide-area computer networks, 
local-area computer networks and computer communi- 
cations througii teleptione lines. In one embodiment of 
the present invention, the interactive network 80 includes 
a cable television system interfaced with an ATM net- 
work. 

In the embodiment illustrated in FIG. 1 the payment 
module 20 is in the remote control unit and communi- 
cates with the cable box 60. The cable box then transmits 
desired data to the network 80 through the connector 50. 
The cable box 60 also receives data from the remote sys- 
tem 200 through the network 80 and connector 50. The 
data received by the cable box 60 may be sent to the 
payment module 20 or the display screen 40, or both. 

The user's local system 100 receives programming 
from a programming source 110 communicated through 
the network 80. In the illustrated embodiment, a network 
interface receives the programming and sends it to the 
display 40 through communication line 70, such as a tel- 
evision antenna cable. The programming may include 
various television stations as well as programming di- 
rected to an at-home retail system for selling to consum- 
ers various goods and services, in use. the user 10 may 
select among the various programs received by the local 
system 100. such as by changing channels on a televi- 
sion set, in the preferred cable television embodiment, 
or by selecting among menus in the computer-based em- 
bodiment. 

In an alternative embodiment, as illustrated in FIG. 
3. the payment module 20 is separate from the controller 
22. which is illustrated as remote control unit 22. The 
payment module 20 communicates with the display 40. 
either by a wired, or non-wired connection 32 and with 
the network through connector lines 52 and 50. The in- 
terlace unit 60. such as a cable box. communicates with 
the network through line 50 and the display through line 
70. 

In the embodiment depicted in FIG. 4, the payment 
module is integrated with the display into one payment 
module/display unit 42. The payment module/display 
unit 42 may communicate with the network either directly 
through a connector or. as illustrated, through communi- 
cation line 70. interface 60 and connector line 50. 

The preferred payment module 20 is a hand-held de- 
vice capable of input by the user and sending output sig- 
nals to a receiving device (such as display 40 or network 
interface 60). In one embodiment, as illustrated in FIG. 
5. the payment module 20 includes an user input device, 
such as keypad 23. Preferably the keypad 23 contains 
the typical input keys used in television remote control 
devices, such as numerals from 0 through 9, channel 
control keys, and volume control keys. Alternatively, or 
additionally, the payment module may include other input 
devices such a light pen, mouse or touch-screen display. 
The keypad 23 communicates with data bus 25 for inter- 
action with other components of the payment module 20. 
A data processor, such as microprocessor ("MP") 26 is 



included to control the payment module functions. A pro- 
gram and information storage device 28 (such as a pro- 
grammable read only memory) provides storage for data 
pertaining to the user's payment accounts as well as soft- 

5 ware control of the payment module's processes. Other 
forms of memory devices may be used. For example, 
magnetic storage devices (i.e. disk drives), optical stor- 
age devices or any solid state storage device may be 
used as well as storage devices. The memory devices 

70 may be remote from the payment module (such as mem- 
ory in an interface device, the display or in an off-site 
location). Output adapter 29 provides for remote com- 
munication between the payment module 20 and the re- 
ceiving device, 

?5 In use. the payment module must be initialized with 

payment account passwords (i.e. "PINs") and other in- 
formation related to the desired payment accounts. Any 
type of payment account may be used, such as credit 
card accounts, debit card accounts or checking ac- 
20 counts. Likewise, it is preferred to initialize the payment 
module with an access password, which will be called 
the "payment module password". 

A preferred first step of the initialization process is 
to initialize the payment module with encryption keys 300 
25 compatible with the DUKPT technique. Preferably, this 
initialization is performed by a service provider such as 
the entity providing the remote financial transaction serv- 
ice. This way, the service provider may maintain decrypt- 
ing keys or may provide them to the appropriate institu- 
te tion. 

A next step of the initialization process is to initialize 
the payment module with user information correspond- 
ing to each payment account selected for use with the 
payment module. Preferably this is performed by a user 

35 using the payment module illustrated in FIG. 5, The user 
inputs the information using keypad 23. The information 
is stored in the payment module, such as in the program 
and information storage device 28. instructions, menus 
and prompts are provided to the display 40 by commu- 

-io nication with the payment module (such as using output 
29). 

In the embodiment illustrated in FIG. 6, the payment 
module is initialized with information corresponding to a 
first credit card in step 310. Typically, the information in- 

^5 put in this credit card initialization step 310 corresponds 
to Track 1 or Track 2 card data. Track 1 or Track 2 data 
are generally encoded on a magnetic strip on debit and 
credit cards. A magnetic strip reader is required to ac- 
quire the information off the magnetic strip. In use. the 

50 owner may swipe the card through the reader to have 
the data read. Track 1 data typically corresponds to the 
card owner's name, account number expiration date and 
card verification value ("C VV") or a PIN verification value 
("PVV"). The CVV and PVV are used to verify other in- 

55 formation using known techniques. They generally are 
data values corresponding to other data on the magnetic 
stripe and are generated by the card issuer. Track 2 data 
typically is the same as the Track 1 data, but does not 
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include the card owner's name. 

The user infornnation entered in step 310 may cor- 
respond to the Track 1 or Track 2 data, or both, or some 
other set of information. The information is entered by 
the user into the payment module. Preferably, the card 
issuer provides the user 10 with a sequence of charac- 
ters which the user enters into the payment module. The 
sequence of numbers corresponds to the user informa- 
tion for entry in step 310. In the preferred embodiment, 
the payment module 20 sends signals to the display 40 
corresponding to graphical menus and prompts and 
thereby leads the user through the data entry in a 
step-by*step process. Then, once data has been en- 
tered, a verification procedure 320 is applied. A typical 
verification procedure employs a known logical redun- 
dancy check in which characters are entered by the user 
in order to check to see if the user information was en- 
tered correctly. If an error is detected, a data correction 
sequence 330 is requested by the payment module. If 
no errors are detected, the initialization process contin- 
ues to the next step. 

In the next step 340. the user is prompted to enter 
the encrypted PIN associated with the card being initial- 
ized. The encrypted PIN may be provided by any 
processing step 345. In the preferred embodiment, the 
user is supplied with a paper encryptor. as discussed 
above. The paper encryptor is used to generate an en- 
crypted PIN using an encryption key preferably main- 
tained by the card issuer. The encryption key preferably 
is not maintained on the payment module. Hostile access 
to the payment module thereby will not yield the encryp- 
tion key. The encrypted PIN is input by the user into the 
payment module, as directed by instructions provided to 
display 40 and the encrypted PIN is stored in the pay- 
ment module. 

In the next step 350. the system preferably inquires 
into whether or not there are additional cards to initialize. 
If there are additional cards, processing line 360 is fol- 
lowed and the additional cards are initialized as in steps 
310-350. If there are no additional cards, processing 
continues on to the final initialization step. 

In the final initialization step 370, the user is prompt- 
ed to select a payment module password that will be 
used to control access to the payment module. The pay- 
ment module password is then entered into the payment 
module and is stored, such as in the program and infor- 
mation storage device 28. Preferably, the payment mod- 
ule 20 may function as a remote controller for the display 
40 or interface/cable box 60. without requiring input of 
the payment module password. Likewise, limited pay- 
ment functions also would be enabled with input of the 
payment module password. Instead, the payment mod- 
ule password would be for enabling access to the order- 
ing or payment system. Thus, the user's payment ac- 
counts and encrypted PINs only could be used by that 
user. 

In an alternative embodiment payment module 
passwords and payment account information may be in- 



put by more than one user. Access to each user's pay- 
ment accounts is limited the users' respective payment 
module passwords. 

In another embodiment, the payment module may 

5 be initialized with payment account information at a 
processing center, such as a bank. In this embodiment, 
the processing center has a magnetic strip reader which 
is connected to the payment module such that it may 
transmit data to the payment module. The magnetic strip 

10 reader thus supplements or supplants the keypad 23 as 
an input device for the initialization process. The opera- 
tor swipes the selected cards through the magnetic strip 
reader. This swiping is done jn a way enabling the mag- 
netic strip reader to read desired information off the mag- 

15 netic strip, such as Track 1 or Track 2 information. The 
magnetic strip reader then outputs the desired informa- 
tion automatically to the payment module and the pay- 
ment module stores the information as discussed previ- 
ously. In addition, the user may input desired PINs into 

20 the magnetic strip reader, such as by using an associat- 
ed keypad. The magnetic strip reader then can process 
the input PINs to encrypt them and the encrypted PINs 
are sent on to the payment module for storage. 

In operation, various financial transactions may be 

25 performed using the payment module. In a typical trans- 
action, which is illustrated in FIG. 7. the user may pur- 
chase goods or services. The payment module may also 
be used to perform electronic fund transfers, such as to 
pay bills and transfer funds between various accounts. 

30 Common to all these transactions is the automatic 
provision of the account information (such as Track 1 or 
Track 2 data) and encrypted PINs by the payment mod- 
ule without any input of the information or unencrypted 
PINs by the user, with the exception of the payment mod- 

25 ule password, which can be entered to access the finan- 
cial transaction feature of the payment module. The 
number of passwords/PINs that a user must remember 
and deal with is thereby reduced. 

In operation, the purchase transaction is guided by 

•^0 a sequence of interactive prompts appearing on the dis- 
play 40. Preferably the prompts are provided by the pay- 
ment module 20. but they also may come from a remote 
location through the network. In a typical transaction, the 
user is prompted to enter his payment module password. 

•^5 as indicated in step 400. The user is then directed 
through prompts and menus to select a particular trans- 
action. 

In making a purchase, the item(s) desired is speci- 
fied. For example, the user specifies the goods or serv- 

50 ices desired 410 (such as by entering a product code), 
and the quantity desired 420. The user then is preferably 
prompted to verify a dollar amount corresponding to the 
desired purchase 430. If the user disagrees with the dol- 
lar amount, processing is returned to step 410 for re-se- 

55 lection of the item(s) desired. 

After the dollar amount is verified, the user selects 
a payment method 440. The payment method is one of 
the payment accounts with which the payment module 
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is initialized. For example, the user may select among 
various credit or debit cards with which the payment 
module was initiaiized. Preferabiy, the user selects the 
desired payment account by pressing an appropriate se- 
lection on the keypad 23. as indicated on a menu dis- 
played on the display 40. 

In step 450, for additional security, the payment 
module then encrypts a second time the previously en- 
crypted PIN corresponding to the selected payment 
method. This encryption 450 may be performed using 
any encryption technique but preferably performed using 
the DUKPT technique. Similarly, desired account infor- 
mation is encrypted in step 450. The account information 
may correspond to the Track 1 . Track 2 or other desired 
account information. 

The doubly encrypted PIN and encrypted account 
information are then transmitted through the interactive 
network 80 as shown in step 460. 

The interactive network preferably is in communica- 
tion with a processing institution 90, such as a bank's 
processing department. A plurality of other processing 
institutions also can be connected in with the network, 
such that the user, or the entity offering the in-home pur- 
chasing system could select among processing institu- 
tions. 

The encrypted PIN and account information are re- 
ceived by the processing institution 90 through the net- 
work 80 as depicted in step 500. The processing institu- 
tion 90 would then identify the payment account from the 
account information as indicated in step 510. Typically, 
the processing institution 90 receives the encrypted PIN 
and account information in a data processing system. 
The data processing system decrypts the encrypted ac- 
count information. From the decrypted account informa- 
tion, the data processing system identifies the payment 
account number and identifies the institution 95 main- 
taining the account, such as the pertinent bank or finan- 
cial institution, as indicated in step 520. Typically, the in- 
stitution maintaining the account is identifiable from the 
account numbers because payment account numbers 
generally include an identifiable code specific to each is- 
suing institution. 

The processing institution then transmits the en- 
crypted PIN and the account information (either encrypt- 
ed or unencrypted) through the network 80 to the pay- 
ment account institution 95. The payment account insti- 
tution then decrypts the encrypted PIN and the account 
information, if necessary, as indicated in step 530. Typ- 
ically, the payment account institution 95 receives this 
data in a data processing system. The data processing 
system decrypts the encrypted account information. The 
account number and PIN preferably are verified and then 
the payment account institution 95 determines whether 
to approve or decline the transaction, as indicated in step 
540. For example, with respect to verification, the insti- 
tution may verify the account number by checking a da- 
tabase of existing account numbers: and the institution 
may verify the PIN by ascertaining that it corresponds to 



the PIN assigned to that account number. With respect 
to determining whether to approve or decline a transac- 
tion, such as a purchase, the institution may check the 
desired purchase price against a credit limit on the ac- 

5 count: if the purchase will exceed a credit limit, the trans- 
action typically will be declined. 

Once the payment account institution 95 determines 
whether it will approve or decline the transaction, an ap- 
prove/decline message is sent through the network 80 

10 back to the local system. 

Thus, It is seen that a remote financial transaction 
system is provided. One skilled in the art will appreciate 
that the present invention can be practiced by other than 
the preferred embodiments which are presented for pur- 

is poses of illustration and not of limitation, and the present 
invention is limited only by the claims which follow. 



Claims 

20 

1. A method for performing remote financial transac- 
tions using a payment module (20) which communi- 
cates with an off-site processing system, wherein 
the payment module accesses a memory for storing 
2S data identifying at least one payment account and 
at least one password, the method characterised by: 
providing information identifying a payment 
account by the payment module to the off-site 
processing system wherein the information identtfy- 
30 ing the payment account is based upon data stored 

in the memory: and 

providing an encrypted password by the pay- 
ment module to the off-site processing system. 

55 2- The method of claim 1 characterised by further com- 
prising, prior to the providing information identifying 
a payment account step, the step of initializing the 
payment module (20) wherein the initializing step 
only needs to be performed one time for each 
•^0 desired payment account, and wherein the initializ- 

ing step comprises the steps of: 

storing information identifying at least one pay- 
ment account in the memory: and 

storing at least one encrypted password in the 
-^s memory wherein each payment account for which 

identifying information is stored in the payment mod- 
ule has at least one corresponding stored encrypted 
password. 

so 3. The method of claim 2 characterised by further com- 
prising storing an access password in the memory. 

4. The method of claim 2 or 3 characterised by: 

encrypting the encrypted password provided 
55 in the providing an encrypted password step before 
the providing an encrypted password step. 

5. The method of claim 4 wherein the encrypting step 
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is performed using a derived unique keys per trans- 
action technique. 

6. A nnethod as claimed in any of one of the preceding 
claims, characterised by further comprising encrypt- 
ing the information identifying a payment account 
prior to the providing information identifying a pay- 
ment account step. 

7. The method of claim 6 characterised in that the 
encryption of the information identifying a payment 
account step is performed using a derived unique 
keys per transaction technique. 

8. A method as claimed in any one of the preceding 
claims, characterised by further comprising before 
the providing information identifying a payment 
account step: 

entering an access password into the payment 
module (20) wherein the correct access password 
must be entered before a remote financial transac- 
tion may be performed: and 

determining whether the correct access pass- 
word was entered. 

9. A method as claimed in any one of the preceding 
claims, characterised by further comprising the step 
of selecting a payment account and wherein: 

the step of providing information identifying a 
payment account comprises providing information 
identifying the payment account selected in the 
selecting step: and 

the step of providing an encrypted password 
comprises providing an encrypted password corre- 
sponding to the payment account selected in the 
selecting step. 

10. A method as claimed in any one of the preceding 
claims, characterised by further comprising before 
the providing information step, the step of providing 
the user a selection of financial transactions. 

11. A method as claimed in claim 1 0 further comprising 
after the step of providing the user a selection of 
financial transactions, the step of selecting a finan- 
cial transaction. 

12. A method as claimed in any one of the preceding 
claims, characterised by further comprising the step 
of sending an approve/decline message from the 
off-site processing system to the payment module. 

13. A method as claimed in any one of the preceding 
claims, characterised in that the providing informa- 
tion step comprises providing the information iden- 
tifying a payment account to a cable television trans- 
mission system. 



14- A method as claimed in any one of claims 1 to 12, 
characterised in that the providing information step 
comprises providing the information identifying a 
payment account to an ATM network. 

5 

15. A method as claimed in claim 9 wherein the step of 
selecting a payment account comprises: 

providing a graphical display on a display 
screen listing payment accounts: and 
10 choosing a payment account from among the 

payment accounts listed on the display. 

16. A method as claimed in claim 15, characterised in 
that the step of choosing a payment account com- 

15 prises: 

moving an indicator symbol displayed on the 
display screen to a location corresponding to the 
desired payment account using an input device. 

20 17. A method as claimed in any one of the preceding 
claims, characterised by displaying menus and 
prompts on a display device: and 

performing a remote financial transaction 
using the menus and prompts. 

25 

18. A method as claimed in any one of the preceding 
claims, characterised by determining whether to 
approve or decline the financial transaction by the 
off-site processing system. 

30 

19. A method of claim 1 , characterised by further com- 
prising the step of selecting a payment account prior 
to the providing information identifying a payment 
account step. 

35 

20. A method of claim T characterised in that the 
encrypted password is based upon data identifying 
at least one password stored in the memory. 

21. The method of claim 1. characterised in that the data 
identifying at least one payment account comprises 
data corresponding to at least one payment account 
from an account maintaining institution further com- 
prising: 

^5 authorization by the account maintaining insti- 

tution allowing the payment account to be used. 

22. A method for initializing an apparatus for perlorming 
remote financial transactions wherein the apparatus 

50 includes a payment module (20) having access to a 
memory for storing data, the method including: 

storing information identifying at least one pay- 
ment account in the memory: 

encrypting at least one password to produce 
55 at least one encrypted password wherein each pay- 
ment account for which identifying information is 
stored in the payment module has at least one cor- 
responding password: and 
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storing the at least one encrypted password in 
the memory. 

23. A method of initializing an apparatus for performing 
remote financial transactions as claimed in claim 22 
wherein the encrypting step is performed with at 
least one paper encryptor. 

24. A method of initializing an apparatus for performing 
remote financial transactions as claimed in claim 22 
wherein the information identifying at least one pay- 
ment account comprises data corresponding to at 
least one payment account from an account main- 
taining institution, the method further comprising: 

authorization by the account maintaining insti- 
tution allowing the payment account to be used in 
conducting financial transactions using the payment 
module. 

25. Apparatus for performing remote financial transac- 
tions having communication with an off -site process- 
ing system, characterised by: 

a payment module (20) for conducting a finan- 
cial transaction wherein the payment module can 
communicate with the off-site processing system: 
and 

a memory accessible by the payment module 
(20) for storing data identifying at least one payment 
account and at least one password. 

26. The apparatus of claim 25, characterised by further 
comprising an interactive network for carrying data 
wherein the payment module (20) is in communica- 
tion with the interactive network for sending and 
receiving data and the off-site processing system 
receives data from and sends data to the payment 
module using the interactive network. 

27. An apparatus as claimed in claim 25 or claim 26, 
characterised in that the memory is a component of 
the payment module (20). 

28. An apparatus as claimed in any one of claims 25 to 

27, characterised in that the payment module com- 
prises: 

means for providing information identifying a 
payment account to the off-site processing system 
wherein the information identifying the payment 
account is based upon data stored in the memory: 
and 

means for providing an encrypted password to 
the off -site processing system. 

29. An apparatus as claimed in any one of claims 25 to 

28. characterised by further comprising means for 
encrypting the encrypted password. 

30. The apparatus of claim 29 wherein the means for 



encrypting uses a derived unique keys per transac- 
tion technique. 

31. An apparatus as claimed in any one of claims 25 to 
5 30, characterised by further comprising: 

means for entering an access password into 
the payment module wherein the correct access 
password must be entered before a remote financial 
transaction may be performed: and 

means for determining whether the correct 
access password was entered. 

32, The apparatus of claim 28, characterised by further 
comprising means for selecting a payment account 

?5 and wherein: 

the means for providing information identifying 
a payment account comprises means for providing 
information identifying the payment account 
selected in the selecting means: and 

^0 the means for providing an encrypted pass- 

word comprises means for providing an encrypted 
password corresponding to the payment account 
selected in the selecting means. 

25 33. The apparatus of claim 28, characterised by further 
comprising means for providing the user a selection 
of financial transactions. 

34. The apparatus of claim 26, characterised in that the 
30 interactive network comprises a cable television 

transmission system. 

35. The apparatus of claim 26, charactensed in that the 
interactive network comprises an ATfVt network. 

35 

36. The apparatus of claim 26, characterised in that the 
interactive network comprises an EFT-POS net- 
work. 

•^o 37. The apparatus of claim 25, characterised by further 
comprising: 

a display screen responsive to instructions 
provided by the payment module. 

-^5 38. An apparatus as claimed in claim 37, characterised 
in that the payment module further comprises an 
input device, and means for providing an indicator 
symbol displayed on the display screen using the 
input device. 

50 
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